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1 This action is in response to the communication filed on 7/25/2008. 

2 DETAILED ACTION 

3 Continued Examination Under 3 7 CFR 1. 114 

4 A request for continued examination under 37 CFR 1.114, including the fee set forth in 



5 37 CFR 1 .17(e), was filed in this application after final rejection. Since this application is 

6 eligible for continued examination under 37 CFR 1.1 14, and the fee set forth in 37 CFR 1.17(e) 

7 has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 

8 37 CFR 1.114. Applicant's submission filed on 7/25/2008 has been entered. 
9 



1 0 Response to Arguments 

1 1 Applicant's arguments filed 7/25/2008 have been fully considered but are moot in view of 

12 the new grounds of rejection presented below. 

13 Claims 1-66, and 68 have been examined. 

14 All objections and rejections not set forth below have been withdrawn. 

1 5 Claim Rejections - 35 USC §103 

16 The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

17 obviousness rejections set forth in this Office action: 

18 (a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 

1 9 section 102 of this title, if the differences between the subject matter sought to be patented and the prior ai t are 

20 such that the subject matter as a whole would have been obvious at the time the invention was made to a person 

2 1 having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 

22 manner in which the invention was made. 

23 

24 Claims 1-6, 10-19, 21, 23-28, 32-42, 44-52, 56-64, 66, and 68 rejected under 35 U.S.C. 

25 103(a) as being unpatentable over Brezak et al. (US Patent Application Publication 

26 2003/00 18913) hereinafter referred to as Brezak, further in view of Ganesan (US Patent Number 
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1 5,557,678), and further in view of Brezak et al. (US Patent Application Publication 

2 2002/0 1 50253) hereinafter referred to as Brezak2. 

3 Regarding claim 1, Brezak disclosed a method of authenticating a client to a content 

4 server (See Brezak Abstract and Fig. 2) comprising the steps of: generating, by a ticket authority 

5 (See Brezak Fig. 2 Element 206), a first ticket (TGT or service ticket A) and a second ticket 

6 (Service Ticket for target server C) wherein said second ticket is disabled from use (See Brezak 

7 Paragraphs 0042-0043 and 0045); transmitting, by said ticket authority, said first ticket to said 

8 client (See Brezak Paragraph 0042-0043); validating, by said ticket authority, said first ticket 

9 (See Brezak Paragraphs 0043 and 0045-0048); using, by said client, said first ticket to establish a 

10 communication session with a content server proxy after said first ticket is validated (See Brezak 

1 1 Paragraphs 0043-0045); enabling, by said ticket authority, said second ticket for use upon said 

12 validation of said first ticket, said enabled second ticket can be validated by said ticket authority 

13 (See Brezak Paragraphs 0045-0048); and using, by said content server proxy, said enabled 

14 second ticket to establish a communication session with said content server (Sec Brezak 

15 Paragraphs 0045-0048), but failed to disclose generating the disabled second ticket before the 

16 first ticket was validated, or that the disabled second ticket cannot be validated by the ticket 

17 authority until enabled by said ticket authority. 

1 8 However, it was well known in the art at the time of invention that, in order to avoid 

19 processor overloading, instead of generating data upon request, the data can be pre-generated and 

20 stored for use when requested (See Ganesan Col. 8 Final paragraph). 

2 1 Brezak2 teaches that upon receipt of a request for a service ticket, once the request has 

22 been validated, the ticket issuer sets the service ticket's flags and certain fields of the service 
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1 ticket are filled in using information from the request, as well as through generation at the time 

2 of filling, such as the validity period start/end times, and a new random session key (See Brezak2 

3 Paragraphs 0059-0063). Brezak2 further teaches that once the ticket's fields are full, the ticket is 

4 encrypted and transmitted to the requestor (See Brezak2 Paragraph 0063). 

5 It would have been obvious to the ordinary person skilled in the art to have employed 

6 what was common in the art in the ticketing system of Brezak by having the TTP pre-generate 

7 and store at least the service tickets prior to receiving a request for these tickets. This would 

8 have been obvious because the ordinary person skilled in the art would have been motivated to 

9 have avoid processor overloading in the event of a large number of simultaneous requests. 

10 It further would have been obvious to the person skilled in the art to have employed the 

1 1 teachings of Brezak2 in the system of Brezak by filling in the appropriate fields in the service 

12 ticket, including the validity period start/end times, upon validation of the ticket request from 

13 Server A. This would have been obvious because the ordinary person skilled in the art would 

14 have been motivated to ensure that the ticket contained the proper data for the requester, and that 

15 the data was fresh. 

16 Regarding claim 23, Brezak disclosed a system for authenticating a user (See Brezak 

17 Abstract and Fig. 2) comprising: a client (See Brezak Fig. 2 Element 202); a ticket authority (See 

18 Brezak Fig. 2 Element 206); a content server (See Brezak Fig. 2 Element 214); and a content 

19 server proxy (See Brezak Fig. 2 Element 210) in communication with said client, said ticket 

20 authority, and said content server (See Brezak Fig. 2), wherein said ticket authority generates a 

21 first ticket (TGT) and a second ticket (Service Ticket), wherein said first ticket is transmitted to 

22 said client and used to establish a first communication session with said content server proxy 
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1 (See Brezak Paragraphs 0042-0043 and 0045), and wherein said second ticket is transmitted to 

2 said content server proxy and used to establish a second communication session with said 

3 content server (See Brezak Paragraphs 0043 and 0045), but failed to disclose generating the 

4 disabled second ticket before the first ticket was validated, or that the disabled second ticket 

5 cannot be validated by the ticket authority until enabled by said ticket authority. 

6 However, it was well known in the art at the time of invention that, in order to avoid 

7 processor overloading, instead of generating data upon request, the data can be pre-generated and 

8 stored for use when requested (See Ganesan Col. 8 Final paragraph). 

9 Brezak2 teaches that upon receipt of a request for a service ticket, once the request has 

10 been validated, the ticket issuer sets the service ticket's flags and certain fields of the service 

1 1 ticket are filled in using information from the request, as well as through generation at the time 

12 of filling, such as the validity period start/end times, and a new random session key (See Brezak2 

13 Paragraphs 0059-0063). Brezak2 further teaches that once the ticket's fields are full, the ticket is 

14 encrypted and transmitted to the requestor (See Brezak2 Paragraph 0063). 

15 It would have been obvious to the ordinary person skilled in the art to have employed 

16 what was common in the art in the ticketing system of Brezak by having the TTP pre-generate 

17 and store at least the service tickets prior to receiving a request for these tickets. This would 

1 8 have been obvious because the ordinary person skilled in the art would have been motivated to 

19 have avoid processor overloading in the event of a large number of simultaneous requests. 

20 It further would have been obvious to the person skilled in the art to have employed the 

2 1 teachings of Brezak2 in the system of Brezak by filling in the appropriate fields in the service 

22 ticket, including the validity period start/end times, upon validation of the ticket request from 
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1 Server A. This would have been obvious because the ordinary person skilled in the art would 

2 have been motivated to ensure that the ticket contained the proper data for the requester, and that 

3 the data was fresh. 

4 Regarding claim 45, Brezak disclosed a system for authenticating a user (See Brezak 

5 Abstract and Fig. 2) comprising: a client (See Brezak Fig. 2 Element 202); a ticket authority 

6 generating a first ticket (TGT) and a second ticket (Service Ticket) wherein said second ticket is 

7 disabled from use (See Brezak Paragraphs 0042-0043 and 0045); a content server (See Brezak 

8 Fig. 2 Element 214); a content server proxy in communication with said client, said ticket 

9 authority, and said content server (Sec Brezak Fig. 2 Element 2 1 0) and receiving said first ticket 

10 (See Brezak Paragraphs 0042-0044); and a web server in communication with said client and 

1 1 said ticket authority (See Brezak Fig. 1 Element 178 and Paragraphs 0031-0032), wherein said 

12 content server proxy establishes a first communication session between said client and said 

13 content server proxy after said ticket authority validates said first ticket (See Brezak Paragraphs 

14 0043-0045), wherein said ticket authority enables said second ticket after said validation of said 

15 first ticket, said enabled second ticket can be validated by said ticket authority (See Brezak 

16 Paragraphs 0045-0048), and wherein said content server proxy uses said enabled second ticket to 

17 establish a second communication session with a protocol different from said first 

18 communication session protocol (See Brezak Paragraph 0045), but failed to disclose generating 

19 the disabled second ticket before the first ticket was validated, or that the disabled second ticket 

20 cannot be validated by the ticket authority until enabled by said ticket authority. 
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1 However, it was well known in the art at the time of invention that, in order to avoid 

2 processor overloading, instead of generating data upon request, the data can be pre-generated and 

3 stored for use when requested (See Ganesan Col. 8 Final paragraph). 

4 Brezak2 teaches that upon receipt of a request for a service ticket, once the request has 



5 been validated, the ticket issuer sets the service ticket's flags and certain fields of the service 

6 ticket are filled in using information from the request, as well as through generation at the time 

7 of filling, such as the validity period start/end times, and a new random session key (See Brezak2 

8 Paragraphs 0059-0063). Brezak2 further teaches that once the ticket's fields are full, the ticket is 

9 encrypted and transmitted to the requestor (Sec Brezak2 Paragraph 0063). 

10 It would have been obvious to the ordinary person skilled in the art to have employed 

1 1 what was common in the art in the ticketing system of Brezak by having the TTP pre-generate 

12 and store at least the service tickets prior to receiving a request for these tickets. This would 

13 have been obvious because the ordinary person skilled in the art would have been motivated to 

14 have avoid processor overloading in the event of a large number of simultaneous requests. 

15 It further would have been obvious to the person skilled in the art to have employed the 

16 teachings of Brezak2 in the system of Brezak by filling in the appropriate fields in the service 

17 ticket, including the validity period start/end times, upon validation of the ticket request from 

1 8 Server A. This would have been obvious because the ordinary person skilled in the art would 

19 have been motivated to ensure that the ticket contained the proper data for the requester, and that 

20 the data was fresh. 

21 Regarding claim 68, Brezak disclosed a system for authenticating a user (See Brezak 

22 Abstract and Fig. 2) comprising; means for generating, by a ticket authority, a first ticket (TGT) 
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1 and a second ticket (Service Ticket) (See Brezak Paragraphs 0042-0043 and 0045); means for 

2 transmitting, by said ticket authority, said first ticket to said client (See Brezak Paragraphs 0042- 

3 0043); means for using, by said client, said first ticket to establish a first communication session 

4 with a content server proxy (See Brezak Paragraphs 0043 and 0045); means for transmitting, by 

5 said ticket authority, said second ticket to said content server proxy (See Brezak Paragraphs 0043 

6 and 0045-0048); and means for using, by said content server proxy, said second ticket to 

7 establish a second communication session with a content server (See Brezak Paragraphs 0045- 

8 0048), but failed to disclose generating the disabled second ticket before the first ticket was 

9 validated, or that the disabled second ticket cannot be validated by the ticket authority until 

1 0 enabled by said ticket authority. 

1 1 However, it was well known in the art at the time of invention that, in order to avoid 

12 processor overloading, instead of generating data upon request, the data can be pre-generated and 

13 stored for use when requested (See Ganesan Col. 8 Final paragraph). 

14 Brezak2 teaches that upon receipt of a request for a service ticket, once the request has 

15 been validated, the ticket issuer sets the service ticket's flags and certain fields of the service 

16 ticket are filled in using information from the request, as well as through generation at the time 

17 of filling, such as the validity period start/end times, and a new random session key (See Brezak2 

18 Paragraphs 0059-0063). Brezak2 further teaches that once the ticket's fields are full, the ticket is 

19 encrypted and transmitted to the requestor (See Brezak2 Paragraph 0063). 

20 It would have been obvious to the ordinary person skilled in the art to have employed 

2 1 what was common in the art in the ticketing system of Brezak by having the TTP pre-generate 

22 and store at least the service tickets prior to receiving a request for these tickets. This would 
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1 have been obvious because the ordinary person skilled in the art would have been motivated to 

2 have avoid processor overloading in the event of a large number of simultaneous requests. 

3 It further would have been obvious to the person skilled in the art to have employed the 

4 teachings of Brezak2 in the system of Brezak by filling in the appropriate fields in the service 

5 ticket, including the validity period start/end times, upon validation of the ticket request from 

6 Server A. This would have been obvious because the ordinary person skilled in the art would 

7 have been motivated to ensure that the ticket contained the proper data for the requester, and that 

8 the data was fresh. 



9 Regarding claims 2, 24, and 46, Brezak, Ganesan, and Brezak2 disclosed that 

10 prior to generating said ticket associated with said client, said client is authenticated with a web 

1 1 server (See Brezak Paragraphs 0042-0043). 

12 Regarding claims 3, 25, and 47-48, Brezak, Ganesan, and Brezak2 disclosed that 

13 said ticket authority transmits said first ticket to a web server and said web server transmits said 

14 first ticket to said client (See Brezak Paragraphs 003 1-0032). 

15 Regarding claims 4, 26, and 49, Brezak, Ganesan, and Brezak2 disclosed that said client 

16 transmits said first ticket to said content server proxy (See Brezak Paragraph 0043 and 0044). 

17 Regarding claims 5, 27, and 50-5 1, Brezak, Ganesan, and Brezak2 disclosed that said 

1 8 content server proxy transmits said first ticket to said ticket authority and said ticket authority 

19 transmits said second ticket to said content server proxy upon validation of said first ticket (See 

20 Brezak Paragraphs 0045-0048). 
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1 Regarding claims 6, 10, 28,32, 52 and 56, Brezak, Ganesan, and Brezak2 disclosed that 

2 said content server proxy transmits said second ticket to said content server upon said enabling 

3 of said second ticket (See Brezak Paragraph 0036 and 0045). 

4 Regarding claims 11, 33-34, and 57-58, Brezak, Ganesan, and Brezak2 disclosed that 

5 said ticket authority transmits said first ticket and said disabled second ticket to a web server and 

6 said web server transmits said first ticket and said disabled second ticket to said client (See 

7 Brezak Paragraphs 003 1 -0032 and 0042-0043). 
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1 Regarding claims 12, 35, and 59, Brezak, Ganesan, and Brezak2 disclosed that said client 

2 transmits said first ticket and said disabled second ticket to said content server proxy (See Brezak 

3 Paragraphs 0043 and 0044; The data copied from the request reads on the disabled second 

4 ticket). 

5 Regarding claim 13, Brezak, Ganesan, and Brezak2 disclosed transmitting said disabled 

6 second ticket to at least one of said content server proxy and a web server (See Brezak 

7 Paragraphs 0043; The data copied from the request reads on the disabled second ticket). 

8 Regarding claims 36, and 60, Brezak, Ganesan, and Brezak2 disclosed that said content 

9 server proxy transmits said first ticket and said disabled second ticket to said ticket authority and 

10 said ticket authority enables said disabled second ticket (See Brezak Paragraph 0045; The data 

1 1 copied from the request reads on the disabled second ticket). 

12 Regarding claims 14, 37, and 61, Brezak, Ganesan, and Brezak2 disclosed transmitting 

13 said enabled second ticket to said content server proxy (See Brezak Paragraph 0048). 

14 Regarding claims 15, 38, and 62, Brezak, Ganesan, and Brezak2 disclosed that a 

15 communication session protocol is established between said client and said content server (See 

1 6 Brezak Paragraph 0036). 

17 Regarding claims 16-17, 39-40, and 63-64, Brezak, Ganesan, and Brezak2 disclosed that 

18 a first communication session protocol is established between said client and said content server 

19 proxy and a second communication session protocol is established between said content server 

20 proxy and said content server, wherein said first communication session protocol is different 

21 from said second communication session protocol (See Brezak Paragraphs 0036 and 0043), said 
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1 client communicating with said content server via said first communication session and said 

2 second communication session (See Brezak Paragraphs 0041, 0043, 0044, and Fig. 2). 

3 Regarding claims 18-19, and 41-42, Brezak, Ganesan, and Brezak2 disclosed that a first 

4 communication session protocol is established between said client and said content server proxy 

5 and a second communication session protocol is established between said client and a web 

6 server, wherein said first communication session protocol is different from said second 

7 communication session protocol (See Brezak Paragraphs 003 1 -0032 and 0043). 

8 Regarding claims 21, 44, and 66, Brezak, Ganesan, and Brezak2 disclosed that said 

9 content server proxy is a secure socket layer relay (See Brezak Paragraphs 0048-0049, and 
10 0053). 

1 1 

12 Regarding claims 20, 22, 43, and 65, Brezak, Ganesan, and Brezak2 disclosed a client 

13 system including many features such as accessing web sites (See Brezak Paragraphs 0005 and 

14 0016-0033), and transmitting a second ticket to a proxy server for the use of a specifically 

15 identified server (See Brezak Paragraphs 0048-0049), but failed to disclose that the client 

1 6 comprised a web browser or that the server was identified by its address. 

17 However, it was well known in the art at the time of invention that computers used web 

1 8 browsers for accessing web sites. It was further well know in the art at the time of invention that 

19 servers were identified by their addresses. Therefore, it would have been obvious to the ordinary 

20 person skilled in the art at the time of invention to provide the client with a web browser and to 

2 1 identify the target server by its address. This would have been obvious because the ordinary 
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1 person skilled in the art would have been motivated to apply what was well known and common 

2 in the art at the time. 

3 Claims 7-9, 29-3 1 , and 53-55 are rejected under 35 U.S.C. 103(a) as being unpatentable 

4 over Brezak, Ganesan, and Brezak2 as applied to claims 1 , 23, and 45 above, and further in view 

5 of Litai et al. (US Patent Application Publication Number 2003/0233554) hereinafter referred to 

6 as Litai. 

7 Brezak, Ganesan, and Brezak2 disclosed accessing a target server through a proxy server 

8 using a service ticket (See Brezak Paragraphs 0045-0048) but failed to disclose the specific 

9 method used for the target server to verify the service ticket. 

10 Litai teaches that in a ticketing system, in order for a server to verify a service ticket, the 

1 1 server sends the ticket to the ticket server (See Litai Paragraph 0046). 

12 It would have been obvious to the ordinary person skilled in the art at the time of 



13 invention to employ the teachings of Litai in the ticketing system of Brezak, Ganesan, and 

14 Brezak2 by having the target server send the service ticket to the trusted third party in order to 

15 have the ticket verified. This would have been obvious because the ordinary person skilled in 

16 the art would have been motivated to protect the server from unauthorized access. 



17 

18 Conclusion 

19 Claims 1-66, and 68 have been rejected. 

20 Any inquiry concerning this communication or earlier communications from the 



21 examiner should be directed to MATTHEW T. HENNING whose telephone number is 

22 (571)272-3790. The examiner can normally be reached on M-F 8-4. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 



2 supervisor, Ayaz Sheikh can be reached on (571) 272-3795. The fax phone number for the 

3 organization where this application or proceeding is assigned is 571-273-8300. 



5 Application Information Retrieval (PAIR) system. Status information for published applications 

6 may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 

7 applications is available through Private PAIR only. For more information about the PAIR 

8 system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 

9 system, contact the Electronic Business Center (EBC) at 866-2 1 7-9 1 97 (toll-free). If you would 

10 like assistance from a USPTO Customer Service Representative or access to the automated 

1 1 information system, call 800-786-9 1 99 (IN USA OR CANADA) or 57 1 -272- 1 000. 



4 



Information regarding the status of an application may be obtained from the Patent 



12 
13 
14 



/Matthew T Henning/ 

Primary Examiner, Art Unit 2131 



